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Special-Purpose IP Address Registries 


Abstract 


This memo reiterates the assignment of an IPv4 address block 
(192.0.0.0/24) to IANA. It also instructs IANA to restructure its 
IPv4 and IPv6 Special-Purpose Address Registries. Upon 
restructuring, the aforementioned registries will record all special- 
purpose address blocks, maintaining a common set of information 
regarding each address block. 


This memo obsoletes RFCs 4773, 5156, 5735, and 5736. 


Status of This Memo 


This memo documents an Internet Best Current Practice. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


BCPs is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6890. 
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Copyright Notice 


Copyright (c) 2013 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


In order to support new protocols and practices, the IETF 
occasionally reserves an address block for a special purpose. For 
example, [RFC1122] reserves an IPv4 address block (0.0.0.0/8) to 
represent the local (i.e., "this") network. Likewise, [RFC4291] 
reserves an IPv6 address block (fe80::/10) to represent link-scoped 
unicast addresses. 


Periodically, the IETF publishes an RFC that catalogs special-purpose 
address blocks. Currently, [RFC5735] catalogs all IPv4 special- 
purpose address blocks and [RFC5156] catalogs all IPv6 special- 
purpose address blocks. 


[RFC5736] assigns an IPv4 address block (192.0.0.0/24) to IANA and 
instructs IANA to allocate special-purpose address blocks from this 
space.  [RFC5736] also instructs IANA to create an IPv4 Special- 

Purpose Address Registry that records allocations from this address 
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space. However, [RFC5736] does not instruct IANA to record special- 
purpose address block reservations from outside of the aforementioned 
Space in the IPv4 Special-Purpose Address Registry. 


Likewise, [RFC2928] assigns an IPv6 address block (2001:0000::/23) to 
IANA and instructs IANA to allocate special-purpose address blocks 
from this space. [RFC4773] instructs IANA to create an IPv6 Special- 
Purpose Address Registry that records allocations from this address 
Space. However, [RFC4773] does not instruct IANA to record special- 
purpose address block reservations from outside of the aforementioned 
Space in the IPv6 Special-Purpose Address Registry. 


This memo reiterates the assignment of an IPv4 address block 
(192.0.0.0/24) to IANA. It also instructs IANA to restructure its 
IPv4 and IPv6 Special-Purpose Address Registries. Specifically, this 
memo instructs IANA to record all special-purpose address blocks in 
the aforementioned registries. These include, but are not limited 
to, IPv4 allocations from 192.0.0.0/24 and IPv6 allocations from 
2001:0000::/23. Furthermore, this memo defines: 


o a common set of information that the registries will maintain 
regarding each special-purpose address block 


o a common set of requirements for future entries 


When the aforementioned registries include all special-purpose 
address blocks, [RFC5735] and [RFC5156] will become redundant with 
the registries. Therefore, this memo obsoletes [RFC5735] and 
[RFC5156]. Because this memo reiterates the assignment of 
192.0.0.0/24 to IANA, and because it restructures the IPv4 Special- 
Purpose Address Registry, it obsoletes [RFC5736]. Finally, because 
this memo restructures the IPv6 Special-Purpose Address Registry, it 
obsoletes [RFC4773]. 


IANA Considerations 
1. Assignment of an IPv4 Address Block to IANA 


Table 7 of this document records the assignment of an IPv4 address 
block (192.0.0.0/24) to IANA for IETF protocol assignments. This 
address allocation to IANA is intended to support IETF protocol 
assignments. A more general view of the roles of IANA with respect 
to address allocation functions is documented in Sections 4.1 and 4.3 
[RFC2860]. 


IANA has designated special-purpose address blocks in compliance with 
[RFC2860]. 
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2.2. Restructuring of the IPv4 and IPv6 Special-Purpose Address 
Registries 
IANA has restructured the following registries: 
o IPv4 Special-Purpose Address Registry 
o IPv6 Special-Purpose Address Registry 
The IPv4 Special-Purpose Address Registry records all IPv4 special- 
purpose address blocks. These reservations include, but are not 
limited to, allocations from the 192.0.0.0/24 address block. 
Likewise, the IPv6 Special-Purpose Address Registry records all IPv6 
Special-purpose address blocks. These reservations include, but are 


not limited to, allocations from the 2001:0000::/23 address block. 


Section 2.2.1 of this document describes information that both 


registries will maintain for each entry. Initially, IANA has 
populated the IPv4 Special-Purpose Address Registry with information 
taken from Section 2.2.2 of this document. Likewise, IANA has 


populated the IPv6 Special-Purpose Address Registry with information 
taken from Section 2.2.3 of this document. 


IANA will update the aforementioned registries as requested in the 
"IANA Considerations" section of a document that has passed IETF 
Review [RFC5226]. The "IANA Considerations" section must include all 
of the information specified in Section 2.2.1 of this document. 


2.2.1. Information Requirements 


The IPv4 and IPv6 Special-Purpose Address Registries maintain the 
following information regarding each entry: 


o Address Block - A block of IPv4 or IPv6 addresses that has been 
registered for a special purpose. 


o Name - A descriptive name for the special-purpose address block. 


o RFC - The RFC through which the special-purpose address block was 
requested. 


o Allocation Date - The date upon which the special-purpose address 
block was allocated. 


o Termination Date - The date upon which the allocation is to be 
terminated. This field is applicable for limited-use allocations 
only. 
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Source - A boolean value indicating whether an address from the 
allocated special-purpose address block is valid when used as the 
Source address of an IP datagram that transits two devices. 


Destination - A boolean value indicating whether an address from 
the allocated special-purpose address block is valid when used as 
the destination address of an IP datagram that transits two 
devices. 


Forwardable - A boolean value indicating whether a router may 
forward an IP datagram whose destination address is drawn from the 
allocated special-purpose address block between external 
interfaces. 


Global - A boolean value indicating whether an IP datagram whose 
destination address is drawn from the allocated special-purpose 
address block is forwardable beyond a specified administrative 
domain. 


Reserved-by-Protocol - A boolean value indicating whether the 
Special-purpose address block is reserved by IP, itself. This 
value is "TRUE" if the RFC that created the special-purpose 
address block requires all compliant IP implementations to behave 
in a special way when processing packets either to or from 
addresses contained by the address block. 


the value of "Destination" is FALSE, the values of "Forwardable" 
"Global" must also be false. 
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2.2.2. IPv4 Special-Purpose Address Registry Entries 


April 2013 


Tables 1 though 16, below, represent entries with which IANA has 
initially populated the IPv4 Special-Purpose Address Registry. 


eS A ea aaa sare ech + 
| Attribute | Value 
E E A A A + 
Address Block 0.0.0.0/8 
Name "This host on this network" 
| REC | [RFC1122], Section 3.2.1.3 | 
| Allocation Date | September 1981 | 
| Termination Date | N/A 
| Source | True | 
| Destination | False 
Forwardable | False 
| Global False 
| Reserved-by-Protocol | True 
$2 O A == + 
Table 1: "This host on this network" 
FAS a 4+--------------- + 
| Attribute | Value 
e r e +--------------- + 
| Address Block | 10.0.0.0/8 
| Name | Private-Use | 
RFC | [RFC1918] | 
| Allocation Date February 1996 
| Termination Date | N/A 
| Source | True | 
| Destination | True 
| Forwardable | True 
Global False 
Reserved-by-Protocol False 
E a a R + 
Table 2: Private-Use Networks 
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PO OO AO O O + 
| Attribute | Value 
AO O === AO O 5-5 + 
| Address Block | 100.64.0.0/10 | 
| Name | Shared Address Space | 
| REC | [RFC6598] | 
| Allocation Date | April 2012 | 
| Termination Date | N/A | 
Source True 
Destination True 
| Forwardable | True 
| Global | False | 
| Reserved-by-Protocol | False 
4---------------------- q---------------------- t 
Table 3: Shared Address Space 
$ O O === AA O O O EA + 
| Attribute | Value 
AO O == AA O O + 
| Address Block | 127.0.0.0/8 | 
Name Loopback 
| RFC | [RFC1122], Section 3.2.1.3 | 
| Allocation Date | September 1981 | 
| Termination Date | N/A 
| Source | False [1] | 
| Destination | False [1] 
Forwardable | False [1] 
| Global False [1] 
| Reserved-by-Protocol | True 
AO O O $ O O + 


[1] Several protocols have been granted exceptions to this 
rule. For examples, see [RFC4379] and [RFC5884]. 


Table 4: Loopback 
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A a SEZ E + 
| Attribute | Value 
AZ == R-—-------------- * 
| Address Block | 169.254.0.0/16 | 
| Name | Link Local | 
| RFC | [RFC3927] | 
| Allocation Date | May 2005 | 
| Termination Date | N/A | 
Source True 
Destination True 
| Forwardable | False 
| Global | False 
| Reserved-by-Protocol | True 
E = R-—-------------- * 
Table 5: Link Local 
4-—-------------------- R-—------------- * 
| Attribute | Value 
$2 - = 4+--------------- + 
| Address Block | 192:16:0.0/12. || 
Name Private-Use 
| RFC | [RFC1918] | 
| Allocation Date | February 1996 | 
| Termination Date | N/A 
| Source | True | 
| Destination | True 
| Forwardable | True 
Global False 
| Reserved-by-Protocol | False 
AO T $2 + 


Table 6: Private-Use Networks 
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ai AZ O a + 
| Attribute | Value 
e A O a S + 
| Address Block | 192.0.0.0/24 12] | 
| Name | IETF Protocol Assignments | 
| RFC | Section 2.1 of this document | 
| Allocation Date | January 2010 
| Termination Date | N/A 

Source False 
Destination False 
| Forwardable | False 
| Global | False | 
| Reserved-by-Protocol | False 
AZ O A O a a a + 
[2] Not usable unless by virtue of a more specific 
reservation. 
Table 7: IETF Protocol Assignments 
$ E ETE E E ques E TT * 
| Attribute | value 
A A S + 
| Address Block | 192.0.0.0/29 | 
| Name | DS-Lite | 
| RFC | [RFC6333] | 
| Allocation Date | June 2011 
Termination Date N/A 
Source True 
| Destination | True 
| Forwardable | True 
| Global | False | 
| Reserved-by-Protocol | False 
$2 O AZ O A T + 
Table 8: DS-Lite 
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AO O A 4---------------------------- * 
| Attribute | Value 
ha O ET K + 
| Address Block | 192.0.2.0/24 
| Name | Documentation (TEST-NET-1) | 
| REC | [RFC5737] | 
| Allocation Date | January 2010 
| Termination Date | N/A 

Source False 

Destination False 
| Forwardable | False 
| Global | False | 
| Reserved-by-Protocol | False 
4---------------------- $ O O E + 


Table 9: TEST-NET-1 


4---------------------- 4-------------------- * 
| Attribute | Value 
4---------------------- 4-------------------- * 
| Address Block | 192.88.99.0/24 | 
| Name | 6to4 Relay Anycast | 
RFC [RFC3068] 
| Allocation Date | June 2001 
| Termination Date | N/A | 
| Source | True | 
| Destination | True 
| Forwardable | True 
Global True 
| Reserved-by-Protocol | False 
4---------------------- 4-------------------- * 


Table 10: 6to4 Relay Anycast 
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apa $ + 
| Attribute | Value 
$ E $ + 
| Address Block | 192.168.0.0/16 | 
| Name | Private-Use | 
| RFC | [RFC1918] | 
| Allocation Date | February 1996 | 
| Termination Date | N/A | 
Source True 
Destination True 
| Forwardable | True 
| Global | False 
| Reserved-by-Protocol | False 
E e R-—-------------- * 
Table 11: Private-Use Networks 
4-—-------------------- R-—------------- * 
| Attribute | Value 
$ E $2 + 
| Address Block | 198.18.0.0/15 | 
Name Benchmarking 
| REC | [RFC2544] | 
| Allocation Date | March 1999 | 
| Termination Date | N/A 
| Source | True | 
| Destination | True 
| Forwardable | True 
Global False 
| Reserved-by-Protocol | False 
AO O $2 + 


Table 12: Network Interconnect Device Benchmark Testing 
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AO O A 4---------------------------- * 
| Attribute | Value 
ha O ET K + 
| Address Block | 198.51.100.0/24 | 
| Name | Documentation (TEST-NET-2) | 
| REC | [RFC5737] | 
| Allocation Date | January 2010 
| Termination Date | N/A 
Source False 
Destination False 
| Forwardable | False 
| Global | False | 
| Reserved-by-Protocol | False 
4---------------------- AO O O AE + 
Table 13: TEST-NET-2 
is a ii 4---------------------------- * 
| Attribute | value 
=== 22====2930 9-2 55 $e SSS SSS SSS SS SS EE =P SS + 
| Address Block | 203.0.113.0/24 | 
Name Documentation (TEST-NET-3) 
| REC | [RFC5737] | 
| Allocation Date | January 2010 
| Termination Date | N/A 
| Source | False | 
| Destination | False 
| Forwardable | False 
Global False 
| Reserved-by-Protocol | False 
3333 T AZ O Sac a as + 


Table 14: TEST-NET-3 
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U A AZ taste orate tease + 
| Attribute | Value 
AZ $ O + 
| Address Block | 240.0.0.0/4 
| Name | Reserved | 
| REC | [RFC1112], Section 4 | 
| Allocation Date | August 1989 
| Termination Date | N/A | 
Source False 
Destination False 
| Forwardable | False 
| Global | False | 
| Reserved-by-Protocol | True 
AZ O $ O + 
Table 15: Reserved for Future Use 
$ O AZ E + 
| Attribute | Value 
AZ = $ iman + 
| Address Block | 255.255.255.255/32 | 
Name | Limited Broadcast | 
| RFC [RFCO919], Section 7 
| Allocation Date | October 1984 
| Termination Date | N/A | 
| Source | False | 
| Destination | True 
Forwardable | False 
| Global False 
| Reserved-by-Protocol | False 
AZ O AZ E + 


Table 16: Limited Broadcast 
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2.2.3. IPv6 Special-Purpose Address Registry Entries 


Tables 17 through 28, below, represent entries with which the IANA 
has initially populated the IPv6 Special-Purpose Address Registry. 


q O A Se a ci aci + 
| Attribute | Value 
4---------------------- 4------------------ * 
Address Block ::1/128 
Name Loopback Address 
| RFC | [RFC4291] | 
| Allocation Date | February 2006 | 
| Termination Date | N/A | 
| Source | False | 
| Destination | False 
Forwardable | False 
Global False 
| Reserved-by-Protocol | True 
K T EA 4------------------ * 
Table 17: Loopback Address 
4---------------------- AO + 
| Attribute | Value 
4---------------------- AO A TEE + 
| Address Block | ::/128 
| Name | Unspecified Address | 
RFC | [RFC4291] | 
Allocation Date February 2006 
| Termination Date | N/A | 
| Source | True | 
| Destination | False 
| Forwardable | False 
Global False 
Reserved-by-Protocol True 
4---------------------- AO O + 


Table 18: Unspecified Address 
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AO ee 4--------------------- * 
| Attribute | Value 
AO O T 4--------------------- * 
| Address Block | 64:££9b::/96 
| Name | IPv4-IPv6 Translat. | 
| RFC | [RFC6052] | 
| Allocation Date | October 2010 | 
| Termination Date | N/A | 
Source True 
Destination True 
| Forwardable | True 
| Global | True | 
| Reserved-by-Protocol | False 
4---------------------- AO a + 
Table 19: IPv4-IPv6 Translation Address 
4---------------------- ES ERES ARE RSS + 
| Attribute | Value 
SE ES SS see see SS ata ii + 
| Address Block | ::££££:0:0/96 
Name | IPv4-mapped Address 
| REC [RFC4291] 
| Allocation Date | February 2006 | 
| Termination Date | N/A | 
| Source | False | 
| Destination | False 
Forwardable | False 
| Global False 
| Reserved-by-Protocol | True 
E e R==S29===5=35 coe + 


Table 20: IPv4-Mapped Address 
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N/A 
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HO 4---------------------------- + 
| Attribute | Value 
$ +---------------------------- + 
Address Block | 100::/64 
Name | Discard-Only Address Block 
| 
| 


| 
| 
| REC 
| 
| 


Source 
Destination 
| Forwardable 
| Global 
| Reserved-by-Protocol 
+ E EA AA ea et AS TUER 


| 
[RFC6666] | 
| 
| 


True 
True 


Table 21: Discard-Only Prefix 


+ E A a ae A A A 
| Attribute 


| Address Block 
Name 

REC 

| Allocation Date 

| Termination Date 

| Source 

| Destination 

| Forwardable 

Global 

| Reserved-by-Protocol 


+ 
| 

+ 
| 
| 
| 
| 
| 

+ 


2001::/23 | 
IETF Protocol Assignments 
[RFC2928] 
September 2000 | 
N/A | 
False[1] | 
False[1] 
| 


False[1] 
False[1] 
False 


[1] Unless allowed by a more specific allocation. 
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+ FA O ut, ep gu E A A ete A ste A ute 


Attribute 


Address Block 


Name 
REC 


Allocation Date 
Termination Date 


Source 
Destination 
Forwardable 
Global 


Reserved-by-Protocol 
+ ERE A AE AAA 


Table 23: 


Attribute 


Address Block 


Name 
RFC 


Allocation Date 
Termination Date 


Source 
Destination 
Forwardable 
Global 


Reserved-by-Protocol 


Table 24: 


Registries 


TEREDO 


+ 
| 
+ 
| 
| 
| 
| 
| 

+ 


2001::/32 
TEREDO 
[RFC4380] 
January 2006 
N/A 

True 

True 


2001:2::/48 
Benchmarking 
[RFC5180] 
April 2008 
N/A 

True 

True 


Benchmarking 
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A E $ + 
| Attribute | Value 
$ E $ + 
| Address Block | 2001:db8::/32 | 
| Name | Documentation | 
| RFC | [RFC3849] | 
| Allocation Date | July 2004 | 
| Termination Date | N/A 
Source False 
Destination False 
| Forwardable | False 
| Global | False 
| Reserved-by-Protocol | False 
E R + 
Table 25: Documentation 
$ E e A E S $2 + 
| Attribute | Value 
Ae O $ + 
| Address Block | 2001:10::/28 | 
Name | ORCHID | 
| REC [RFC4843] 
| Allocation Date | March 2007 | 
| Termination Date | March 2014 | 
| Source | False | 
| Destination | False 
Forwardable | False 
| Global False 
| Reserved-by-Protocol | False | 
AZ reana $ + 


Table 26: ORCHID 
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A E $2 + 
| Attribute | Value 
$ == $ + 
| Address Block | 2002::/16 [2] | 
| Name | 6to4 | 
| RFC | [RFC3056] | 
| Allocation Date | February 2001 | 
| Termination Date | N/A 
Source True 
Destination True 
| Forwardable | True 
| Global | N/A [2] 
| Reserved-by-Protocol | False 
E S $2 + 
[2] See [RFC3056] for details. 
Table 27: 6to4 
AZ rE A + 
| Attribute | Value 
$ E = $ + 
| Address Block | £c00::/7 
| Name | Unique-Local | 
| REC | [RFC4193] | 
| Allocation Date | October 2005 | 
| Termination Date | N/A | 
Source True 
Destination True 
| Forwardable | True 
| Global | False | 
| Reserved-by-Protocol | False | 
AO E $2 + 


Table 28: Unique-Local 
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$2 enea AZ ---------- + 
| Attribute | Value 
E E + 
| Address Block | fe80::/10 
| Name | Linked-Scoped Unicast | 
| RFC | [RFC4291] | 
| Allocation Date | February 2006 | 
| Termination Date | N/A | 
Source True 
Destination True 
| Forwardable | False 
| Global | False | 
| Reserved-by-Protocol | True 
S S AZ ------- + 


Table 29: Linked-Scoped Unicast 
Security Considerations 


Security of the Internet's routing system relies on the ability to 
authenticate an assertion of unique control of an address block. 
Measures to authenticate such assertions rely on validation that the 
address block forms part of an existing allocated address block and 
that there is a trustable and unique reference in the IANA address 
registries. 


The proposed registry is intended to provide an authoritative source 
of information regarding the currency and intended purpose of special 
purpose address blocks that are designated from the IANA-administered 
Special-Purpose registry. This is a small step towards the creation 
of a comprehensive registry framework that can be used as a trust 
point for commencing a chain of address validation. Consideration 
should be given to IANA registry publication formats that are machine 
parsable. Additionally, consideration should be given to the use of 
file signatures and associated certificate mechanisms to allow 
applications to confirm that the registry contents are current and 
that they have been published by the IANA. 
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